【レポート】AWS活用事例セミナー~キーマンが語るクラウド推進成功への分岐点~

【レポート】AWS活用事例セミナー~キーマンが語るクラウド推進成功への分岐点~

Clock Icon2019.07.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは韓です。

先日開催されたAWS活用事例セミナー~キーマンが語るクラウド推進成功への分岐点~は自社イベントなのですが、 個人的に興味があり参加してみましたところ大変興味深い内容でしたのでレポートします。

どんなイベント?

詳しくはイベント紹介ページにありますが、概要は以下の通りです。

クラウド化の推進に向け、具体的にはどのように取組めばいいのか、課題に直面した際、どのように解消し、推進していくことが情報システム部門には求められているのか。限られた人員、予算の中で、推進役としての課題をお持ちの企業も多いのではないでしょうか。

2010年にAWSを利用しはじめ、現在はほぼ全サービスがAWSベースとなり、700超のインスタンスという規模で利用されている株式会社IDOM様をお迎えし、AWSの導入から利用拡大に向けての取組事例をご紹介を中心に、AWSの技術動向やAWS導入に関するサービスについてお話いたします。

このエントリではセミナーのメインとなる活用事例についてレポートします。

セッションレポート: AWS活用事例の紹介

スピーカーは 株式会社IDOM SREユニットリーダの月島様。

IDOM社は 中古車の買取・販売の Gulliver をはじめ、 車の定額利用サービスのNOREL、 車の個人売買Guliliverフリマ、 個人間カーシェアGO2GO などを手掛けている。今回はそのAWS化の取り組みについて。

AWS化の検討

従来型のオンプレのDCでは施策反映までの時間がかかることから、新たな環境はクラウドにすべきだという方向性を持っていた。

そこでクラウドにすべきかという選定で、プライベートクラウドを含め数社検討を行った結果AWSにするという結論に達した。

  • クラウドベンダを多数の項目で比較検討
    • AWSは全項目で高得点&穴が無い
    • 決め手はAPIでの操作
    • AWSの印象は "Private on Public Cloud"
  • データセンタに近い構成が組める
    • VPC
    • Direct Connect
    • Tokyo Region
    • EC2(P2V)
  • 構築スピードの向上
  • システム障害時の機会損失の削減
    • DCに行かなくてもいい

どのように着手したか

まずはできるところから

2014年初め、お客様向けのサイトから着手した。

移行の間は見えない課題が多かったが、 業務理解のある既存アプリベンダとAWSの知見のあるクラスメソッドの組み合わせが奏功し、効率的なAWS化を推進できた。

業務システムの移行

移行にあたっての課題

業務システムの特徴:

  • システム数は多い(対象サーバ)
  • 殆どが物理サーバ上で稼働
  • 関連ITベンダが多数
  • つぎはぎシステムが多い
  • いわゆる現場ツール(経営層には響かないけど現場で大事 etc.)
  • 古いOSも多数存在

課題を集約すると以下:

  • 見積が大ブレする、見積に時間がかかる
  • スケジュールが引けない
  • PaaS、SaaSサービスに移行しづらい環境
  • ソフトウェアライセンスがクラウドライセンスに非対応

業務システムの移行方針

  • 出来るシステムから移行
  • AWS上での稼働を優先
  • アプリケーション改修は少なく
  • 新規構築や改修の際にAWSの効果を高める施策を施す

上記方針で推進した結果、課題は以下の様になった:

  • 見積が大ブレする、見積に時間がかかる
    • 適宜、見積もることでブレを失くす
    • 構成か所が最小限なので費用が少ない
    • 変更点が限定的で把握がしやすい、交渉しやすい
  • スケジュールが引けない
    • 目標完了日はもうけるが1年ごとに修正
  • PaaS、SaaSサービスに移行しづらい環境
    • アプリベンダもAWSの特徴を知りて積極的にサービスを利用するようになった
  • ソフトウェアライセンスがクラウドライセンスに対応していない
    • 粘り強く交渉した→「初回ケースとして取組みましょう」

移行の推移

  1. 新規構築または改修の際にAWS化を実施
    • 査定システムの刷新
      • モックアップ作成
      • 仕様書の作成
      • 技術仕様のトランスファー
    • BIツールの構築
    • etc.
  2. 社内およびベンダのナレッジの向上
    • AWSに対する見方が変化
    • 見積精度の向上
  3. 具体的な移行計画が立案できるようになる
    • AWS化が進む

完全移行の結果

2017年度末 データセンターの完全撤廃が出来た。

移行作業の振り返り(当時):

  • 予算の遊びは出なかった
  • 社内に知見がたまった
  • 業務を優先できた
  • 一部、OSなどが古いままリフト&シフトした
    • → 当初の予想どおり
  • 構築スピードが向上した
  • システム障害時の機会損失の削減した

完全移行を終えて得られる更なるメリット

  • コードでインフラ構成ができる
  • AWSのスケーラビリティが享受できる
  • 標準化がしやすい
  • システム・技術に挑戦がしやすい
  • プロジェクト(システム)をスムーズに終結(削除)できる
  • AWSのサービス拡充・進化に乗って、システムが底上げされる
  • 場所を問わずシステム構築・変更ができる
  • 事業に集中できる
  • アプリ・インフラ体制からの脱却がし易い
  • 利用者、事例が多く、より知見を得られやすい

※ 業務システムの移行は、今では楽になっている

  • 事例が沢山だされている
  • ドキュメントが豊富
  • SIerも手を出し始めている
  • 様々なソフトウェアメーカがクラウド対応
  • AWSが凄まじく進化、移行ツール、プロビジョニング、開発ツール
  • コミュニティが成長している(JAWS-UG)

現状と向かうべき方向

  • 取り巻く状況
    • 著しい技術の進化と情報の氾濫
    • 価値観の変化
    • ITとビジネスの融合・変換(DX)
    • 異業種からの市場への参入
  • 向かうべき方向
    • システムの連携性の改善(密結合→疎結合)
    • レガシーからの脱却
    • 作るから使うへ(クラウドサービスの利活用)
    • AWSを使い込む
    • AWSはセキュリティを最優先にしていて、対応、強化が早い
    • サービスが増え、進化している
    • アプリ-インフラの体制から脱却しDevOpsへ

AWS移行を成功に導くには

  • 柔軟で高速なシステム化を行うために、自社のエンジニアリング力をつける
  • AWSなどの最新事例・知見・経験を豊富に持つベンダ(クラスメソッド)の力を借りる
  • IDOMの業務知識を補うために既存(アプリ)ベンダの力を借りる
  • 技術力・エンジニアリング

なぜクラスメソッドなのか?

  • AWSをはじめとした技術力が高い
  • インフラからアプリまで
  • 柔軟な対応、形式に固執しない
  • 事業・業務を理解しようとしてくれる
  • クラウドサービスの様に進化、スケールしている

コミュニティ活動(JAWS-UG)

  • 様々事例やベストプラクティスが出ているが、最終的に自社に会うかは自分で判断するしかない
  • 利用者同士エンジニア同士、知見を共有しあうのがよい

さいごに

ユーザ企業による具体的な事例報告であり食い入るように聞き入る参加者が多く見られました。 特にユーザ企業がテクノロジーを理解し推進する体制をとることでビジネスのアジリティーを獲得できるという話は印象的でした。 クラウド化を検討あるいは取組み始めた方々だけでなく、我々にとっても非常に勉強になる内容でした。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.